4.2.3 ガイド：フィーチャーチームへの移行
LeSS を導入する場合、フィーチャーチームへの移行は一斉に進める
LeSS Huge を導入する場合、いくつかの移行戦略から選択することができる
戦略を決定するのに役立つ手順
(1) 状況を見極める
プロダクトグループの規模
グループ数が少ない方がフィーチャーチームへの移行が簡単
プロダクトの存続期間
長い期間（e.g. 30 年後）存続するであろうプロダクトはゆっくりとした変化を許容でき、表面的にはリスクが低い傾向にある
短い期間（e.g. 数年）しか存続しないであろうプロダクトには余裕がなく、速く変化しなければならない
コンポーネントと機能の専門化の程度
専門化が進んでいると、フィーチャーチームの導入はより大きな変化が必要となる
開発拠点が増えると、フィーチャーチームの導入が難しくなる
拠点が特定のコンポーネントや機能に特化している場合は二重に難しくなる
拠点の専門化は、クロスコンポーネントとクロスファンクショナルな学習の障害になる
(2) 移行戦略を決定する
一斉に
LeSS Huge において一斉に導入するのは必要とする組織変更の量が多いためあまり一般的ではない
以下の条件を満たすときには、良い戦略となる
プロダクトグループが比較的小さいとき
プロダクトの存続期間が短いとき
専門化が少ないとき
開発拠点が 1 つで同一ロケーションであるとき
一斉に LeSS Huge を導入する際は、必要な学習とコーチングの評価に注意（過小評価してしまいがち）
コンポーネントチームの責任を徐々に拡張する
組織の現在の状態をフィーチャーチーム導入マップにプロットし、チームのスコープを拡大する将来の目標を示す（参考: 10 Done の定義） この方法の弱点
メリットが少ない状態でフィーチャーチームとコンポーネントチームの両方の欠点に苦しめられる期間が続く
チームがまだコンポーネントチームである状態で顧客中心の要求エリアを導入することは困難
複数の拠点が存在する環境下では、それぞれの拠点で多くの学習が必要となるので良いアプローチとなる
並列組織
既存のコンポーネントチームの組織は、新しいフィーチャーチームがコードを変更することを除いて、以前と同じように機能する
新しいフィーチャーチームは、価値があるが痛みを伴う（依存度が最も高い）フィーチャーに取り組み、コンポーネントを直接変更し、コンポーネントを越えて作業する
スムーズに運ぶコツ: 新しいフィーチャーチームに入ってもらえる有志を探すこと
この戦略は変化がゆっくりで低リスクのため、巨大な LeSS Huge プロダクトグループに適している
欠点は、時間がかかること
この戦略を使用する場合は若いフィーチャーチームに多くのサポートを提供し、多くの成果は期待してはならない
そのフィーチャーチームは、異なるコンポーネント、異なるコンポーネント構造、異なるツールの使用法、異なるテスト環境における技術的な障害を解決しなければならない
そのフィーチャーチームは、新しいコンポーネントや新しい機能のスキルを学習しなければならない
そのフィーチャーチームは、組織の全ての弱点と機能不全のメッセンジャーとなる